* Move more code from bash to C:

  1. Adapter listing code can use what is currently
     device_sysfs:device_sysfs_list_devices().

     The first option is to parameterise this function with a list of
     sysfs bus types (i.e. for devices probably pass
     device_sysfs_type_alist[] as a parameter and have a similar array
     for adapters).  This would involve moving the core of the
     function to sysfs.[ch] so the logic isn't duplicated.

     Alternatively, notice that in update-lsvpd-db.in,
     process_adapters() and process_devices() do logically the same
     thing.  They just influence the multiplexing differently by
     passing "adapter" or "device" to the node_add and node_add_name.
     Once you have enough code written in C, the supertype information
     will take care of the differences between adapters and devices,
     so those functions can be merged and can call straight out to
     node_handler.  The idea is to add functionality to node_handler
     so that it can eventually be renamed to update-lsvpd-db.in and/or
     can run as a daemon that handles "hotplug" events.

     Note: I would leave the Linux 2.4 compatibility code in
     scripts/scan.d/33adapter_dt_nosysfs there for as long as possible
     and call it as a special case from the adapter listing code.  It
     is reasonably complex, it works and we're not really doing new
     development for Linux 2.4.

  2. Implement some of the class and subdirectory functionality from
     scripts/scan.d/20sysfs in C so that the rest of the adapter VPD
     code (i.e. the "extra VPD hooks") can be moved to C...  and USB
     device support can (probably) be implemented in C (see bug 20958
     in IBM LTC's bugzilla).

  3. Once this is done, I think the "logicals" code can go to C too.
     Logicals are currently used for adapter channels and were an
     interesting design decision (they still seem like the best
     solution).  It might be possible to use them for things like SCSI
     LUNs too, but I haven't thought about it too much.

  At each stage bash code can be carefully removed.  Note that some
  bash code is used in multiple stages, so reimplementing
  functionality in C for use in a particular stage does not guarantee
  that bash code can be removed.  At the moment there is some
  duplicated code.

* Implement support for sub-subtypes of CD-ROM drives using the
  CDROM_GET_CAPABILITY ioctl(2).

* Update bash scripts/modules to not rely on the "local" keyword
  unsetting variables.  The current behaviour is undocumented and ash
  does things differently, so it might change.

* The Linux 2.4 support in scripts/scan.d/33adapter_dt_nosysfs may be
  broken for things like fibre-channel.  It and src/adapter_pci_map.c
  may compare subtypes too strictly.  However, it has probabyl always
  been that way and that code is in maintenance mode.

* Similarly, need to (re-)implement copying of missing device-tree
  segments for hotplug.

* Implement support for getting physical locations for items in a SCSI
  enclosure, probably only on IBM pSeries.

* Locking.

  Consider whether /var/lib/lsvpd should be locked when
  update-lsvpd-db is running.  Currently multiple executions of
  update-lsvpd-db can occur concurrently with little risk.

  Adapter code puts lock files in directory /var/lib/lsvpd/db/../lock/
  but does not attempt to remove them.  This needs to be investigated.

* Implement VPD bus aliases that use a flattened namespace so the
  query commands can find all of the VPD by processing a single
  directory.  This could be done by flattening the directory
  structure, replacing each '/' with '%'.  This may not be faster if
  the directory gets *very* big.  The links would probably point to
  the parent directories, so the sort order would be correct.

  A compromise would be to duplicate the structure and have it contain
  only links to the VPD directories (or their parents).  The advantage
  of this approach is that the directories would be quite sparse and,
  for the device-tree case, wouldn't contain irrelevant
  subdirectories.  Therefore, find should work quicker.

* Move file and directory creation and removal functions like
  lsvpd_mkdir and lsvpd_rm_rf to a file that includes lsvpd.h and make
  them check file or directory arguments against lsvpd_db_dir.

* PN and EC from EEPROM of certain network cards.

  I've now noticed that for 14106902 (although not for the "14108902"
  - also an e1000-based card), the PN and EC appear near the end of
  the EEPROM, which can be got at via the ethtool interface:


  io-bears:~/martins # ethtool -e eth1
  Offset          Values
  ------          ------
  0x0000          00 02 55 d3 5c 56 30 05 ff ff ff ff ff ff ff ff
  0x0010          80 c3 03 64 03 46 69 02 14 10 26 10 86 80 e8 34
  0x0020          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  0x0030          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  0x0040          0c c3 86 72 00 35 02 21 c8 04 ff ff ff ff ff ff
  0x0050          ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 06
  0x0060          2c 00 00 40 04 11 00 00 ff ff ff ff ff ff ff ff
  0x0070          ff ff ff ff ff ff ff ff ff ff ff ff ff ff dd 5c
  0x0080          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  0x0090          ...
  0x01f0          30 30 50 36 31 33 30 48 31 32 38 31 38 20 38 55

  In this case we see:

    PN @ 0x01f0 (7 bytes) = 00P6130
    EC @ 0x01f7 (6 bytes) = H12818

  However, there doesn't seem to be anything else.

  Write a templating system (based on
  vendor/device/subvendor/subsystem-id) to parse the contents of the
  EEPROM.

* VPD from EEPROM on Digi 80P4353 serial card.  This is awaiting
  device driver support.

  sa1         U787E.001.AAA0010-P2-C1-T1    2-Port Asynchronous EIA-232
                                            PCI Adapter

        Displayable Message......... 2-Port Asynchronous EIA-232 PCI Adapter
        Part Number................. 80P4353
        FRU Number.................. 80P4353
        Manufacturer................Digi
        EC Level....................H13251
        Serial Number............... 014132959
        Device Specific.(YL)........U787E.001.AAA0010-P2-C1-T1

* Consider whether
  src/device_scsi_sg_map.c::device_scsi_sg_map_setup() should remove
  any device nodes it creates.  There's a potential for obvious races
  here.  Is it possible to use chroot?

* Consider making PCI 2.2 VPD dynamic.  That is, make the query
  commands retrieve it.

* More adapters in lsmcode.

* Physical location aliases?

* Support system-wide N5 and N6 fields on pSeries:

    The next 2 keywords are also system-wide and are present only on
    systems with a Capacity Upgrade on Demand Capacity Card. N5
    represents the licensed entitlement of Capacity Upgrade on Demand
    (CUoD) processors. N6 represents the licensed entitlement of CUoD
    memory. The values for N5 and N6 are generated by making the
    "ibm,get-system-parameter" RTAS call.

  This is pending a stable RTAS interface... and demand.

* Implement hooks for hotplug and look at dynamic /proc/device-tree.

* Implement a regression testing suite.  This would allow testing of
  various components, although wouldn't allow testing of the overall
  system.

* Ethernet & SCSI adapter VPD is currently synthesised in a minimal
  way.  

  In the longer term some sort of real VPD retrieval needs to be
  implemented. I'm going to look at getting binary blobs with the
  contents of PCI expansion ROMs in /sys.  Note: this happened in
  2.6.10, but I had nothing to do with it...  :-)

* ...
